home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1995 October / EnigmA AMIGA RUN 01 (1995)(G.R. Edizioni)(IT)[!][issue 1995-10][Aminet 7].iso / Aminet / dev / amos / AMOSL0495.lzh / AMOSLIST / 000101_amos-request@svcs1.digex.net_Fri Apr 21 21:43:33 1995.msg < prev    next >
Internet Message Format  |  1995-05-01  |  6KB
  1. Received: from svcs1.digex.net by nfs1.digex.net with SMTP id AA21292
  2.   (5.67b8/IDA-1.5); Fri, 21 Apr 1995 21:43:31 -0400
  3. Received: by svcs1.digex.net id AA15370
  4.   (5.67b8/IDA-1.5 for amos-out); Fri, 21 Apr 1995 15:25:16 -0400
  5. Received: from nfs2.digex.net by svcs1.digex.net with SMTP id AA15366
  6.   (5.67b8/IDA-1.5 for <amos@svcs1.digex.net>); Fri, 21 Apr 1995 15:25:13 -0400
  7. Received: from pool.info.sunyit.edu by nfs2.digex.net with SMTP id AA07393
  8.   (5.67b8/IDA-1.5 for <amos-list@access.digex.net>); Fri, 21 Apr 1995 15:25:11 -0400
  9. Received: (from udcg@localhost) by pool.info.sunyit.edu (8.6.12/8.6.12) id PAA06270; Fri, 21 Apr 1995 15:24:58 -0400
  10. Date: Fri, 21 Apr 1995 15:24:54 -0400 (EDT)
  11. From: "David C. Gorton" <udcg@sunyit.edu>
  12. X-Sender: udcg@pool.info.sunyit.edu
  13. To: amos-list@access.digex.net
  14. Subject: Real-time Window Dragging (Contents and all!)
  15. Message-Id: <Pine.ULT.3.91.950421143404.27316B-100000@pool.info.sunyit.edu>
  16. Mime-Version: 1.0
  17. Content-Type: TEXT/PLAIN; charset=US-ASCII
  18. Status: RO
  19. X-Status: 
  20.  
  21. I saw mention on this list of that hack in Windoze-NT wher you can pick 
  22. up a window, and drag the *whole thing around, not just an outline of the 
  23. border.
  24.  
  25. To try this you better have AT LEAST an accelerated graphics card, some
  26. sort of loca-bus, a Level 2 cache (on top of the normal one), and FAST HD,
  27. and at least a 90 MHz Pentium!  Even then, the HD occasionally goes into
  28. coniptions (Windoze writes everything to the HD for no damn good reason,
  29. bitmap clips included). 
  30.  
  31. Plus, the background redraws can even then be flaky and delayed.  And 
  32. don't count on "multitasking", not that NT really does it right.  So much 
  33. processor time is consumed by this hack, not many cycles are available 
  34. for anything else!  If you're online, you can expect to get serial errors 
  35. (data loss) unless you add a card with a 16 byte FIFO UART, and keep the 
  36. baud rate at 9600 or lower.
  37.  
  38. WHY THE AMIGA CAN DO IT BETTER:
  39.  
  40. I don't do newsgroups, so maybe one of you can repost this proposal.  What
  41. the Amiga does through elegant hardware design, the clones and Macs must
  42. do by dedicating all available processor time to the task...Like the
  43. Amiga-full-screen-dragging.  I'll admit the OS routines for this are
  44. written in Finkel-Fecal-C, but even then it's reasonably fast, due to the
  45. good hardware.  You need a 90 MHz Pentium to even THINK about real-time 
  46. full window dragging. 
  47.  
  48.  Unfortunately there's no Amiga OS patch to do this visually appealing 
  49. window-move.  This is sad, because a 7.159MHz Amiga 1000 for 1985 could 
  50. do it better than a Pentium clone (due to Ami's versatile hardware).
  51.  
  52. I understand the hardware, but my programming skills on the Amiga are 
  53. weak.  Here's how an Amigan could simply create a WorkBench patch to 
  54. create real-time-full-window-dragging.  Maybe one of the better 68K 
  55. programmers could churn this out by next week.
  56.  
  57. 1. When the user grabs a window to drag, a playfield of same dimension of 
  58. the window should be opened.  OCE/ECS or AGA should be checked to 
  59. establish plane/playfield limits...ie: on an OCS system, an 8 color WB 
  60. screen can only open up a 1 plane playfield.  If you can't open enough 
  61. planes for the playfield to represent all the colors in the original 
  62. window, just open up as many planes as hardware will allow, and blit the 
  63. most signigicant color (text usually) into the playfield...you get the 
  64. idea...
  65.  
  66. 2. Once you've got the plafield looking like the window, bring the 
  67. playfield to front, at the same location as the Window.  restore the 
  68. contents under the window (use the OS routine for this).  The system 
  69. thinks you've got ahold of the window...as you drag the mouse, have your 
  70. patch apply the XY coords used by the OS window-drag routine, to the 
  71. playfield.  The playfield moves in realtime...in effect, a HARDWARE WINDOW.
  72.  
  73. 3. When the user lets go of the mousebutton, use the OS routine that 
  74. places the window to it's new XY position.  Then close/deallocate the  
  75. playfield.
  76.  
  77. Notes: On an OCS system, a 4 color WB, and a 4 color playfield on top,
  78. could start to be tad sluggish, if you have a HUGE window.  It'd be like
  79. having a 16 color screen up.  BUT IT STILL EATS LESS CYCLES AND BANDWIDTH
  80. THAN USING THE BLITTER and/or 680X0 to do realtime movement.   Typical 
  81. sized windows, even on an overscanned 720x480  2.1 WB (as inefficient as 
  82. 2.0 and above are) should move pretty fluidly even on a 7MHz Amiga.
  83.  
  84. If you have a 16 color OCS HiRes WB, or a 4 color ECS SuperHiRes WB, or a 
  85. 256 color AGA SuperHires WB, you won't be able to open up a playfield of 
  86. any depth, so any patch should check for this condition.
  87.  
  88. I'm not familiar enough with AGA hardware :-( to know if a 256 color AGA 
  89. HiRes WB would allow for another playfield.  Since this mode only uses 
  90. half of the available video bandwidth (as compared to SuperHires) I would 
  91. suspect that it could allow you to open an 8 plane playfield.  But I'm 
  92. not going to make that assumption.  I have no idea about the other 
  93. goofier modes like 800x600, etc.
  94.  
  95. It's up to you if you want to turn off the OS's 
  96. dragging-outline-of-the-window routine.  The user can't see it (the 
  97. playfield is on top) anyway, and shutting it off will free up quite a few 
  98. cycles!
  99.  
  100. Overacheivers can try to defeat the OS's refusal to write to WB when a 
  101. window is being moved.  This means that WHILE a window is being moved, it 
  102. can have updates occuring in it (like a dir listing or an audio-meter, 
  103. etc), since it's not really on the WB anymore.  Just make sure the 
  104. videomode you're in allows for enough playfield planes to accurately 
  105. reflect all the colors in the original window.  And make sure you tell 
  106. the OS where the new window's (playfield really) memory address is!
  107. If you do this, it also means other bitmaps updates can occur on the WB 
  108. WHILE you're moving your "hardware window".  This would REALLY make the 
  109. Amiga multitasking look appealing, even to ignorant clone owners.
  110.  
  111. In fact, whoever writes the best version of this, ought to offer it to
  112. whoever takes over the Amiga OS, as a part of the forthcoming OS upgrades. 
  113. Sorta like how ARP was offered to CBM, but nipplehead Andy Finkel turned
  114. it down. 
  115.  
  116.  
  117.